Programming GALs in 2022
I am using GALs for some electronic projects. It is a bit of a lost ancient art these days, or maybe I'm doing it wrong and failed to find any modern info.
I need GALs because I make hardware for retro-computers, where the logic uses 5V, so most modern options are out. Surprisingly, Microchip is still producing GALs. Also, the toolchain is mostly free software, and I can run it on Haiku (almost all of it), which is cool. The official closed source software seems unstable and very confusing.
Anyway, so the devices I'm using are the ATF16V8 and ATF22V10C, depending on how much IO I need. They are compatible with JED files designed for the older GAL16V8 and GAL22V10, which mean I can use tools designed for these.
The GAL chips are programmed from "JEDEC" files. These are roughly similar to Intel hex or Motorola S-Record and just describe the state of each fuse inside the GAL. For the simplest devices, the representation is fairly straightforward, but the newer ones add more and more fuses for different functions. It is possible to reverse engineer how a GAL works interally by generating a lot of these files from equations using an existing design tool, and analyzing what changes in the output. The next step can also be analyzed, by looking at an existing GAL programmer with a logic analyzer while it's programming or reading a chip. This is how open source tools came to be developped. It's also not impossible that in the past, some people just decided to edit their JEDEC files directly instead of going through a tool to assemble them from equations. That would have been doable on the first generations of chips, but would get a bit out of control on the current ones, I guess.
My current setup is using galasm for creating JEDEC files from equations, and atfblast to load the JEDEC files into the chip, using a cheap and simple programmer that I could assemble myself.
The original authors for both of these have disappeared off the internet, I hope they are doing ok. Thanks to both of you if you read this.
Currently you can find the sources for galasm on github. The documentation is included, but it may be easier to browse it online from another place where it's hosted. There is also a clone of it called Galette, written in Rust and supposedly much cleaner and easier to maintain (I don't know, I have not looked very closely at the sourcecode of either). So if you're looking to add more features (support more chips, maybe?) it would be a good idea to start there instead. Also it has a better license, since galasm is derived from the older Amiga program GALer, which had a license restricting it to non-commercial use.
For aftblast, you can find documentation about the hardware also on Github. However, the version of the software provided there will not run on current Windows versions (it will appear to, but it is not able to access the parallel port). So you need to get a version modified to use inpout32.dll which allows access to the hardware on modern Windows systems.
With that, you're all set to program these GALs.
Of course, it would be great to be able to program newer devices too, like the ATF750. It looks like there is some work in progress on that in the "afterburner" arduino based GAL programmer. But there is no effort from the galasm side to allow it, so the equations would need to be assembled in WinCUPL or some other tool.
The algorithm for programming the chips is now well understood, for example it is documented here. It's unfortunate that Atmel/Micrchip does not want to give any information, but in the end the algorithm is deried from the one used for previous GALs and so it isn't so hard to adjust it (different address and data sizes, pretty much).
This document also explains how the fuses work, and, completing it with what was discovered about the ATF750, and careful reading of the datasheet (it does give some fuse line and column address in the block schematics, for example, but doesn't explain what they are), it should be possible to build a new version of galasm or galette for the newer chips. That seems like a large-ish project, and certainly it isn't a great idea to start working on both the assembler and the programmer at the same time. Also it's questionable if galasm should be used as a base at all, it is old and obscure, and also very low level (it would be nice to be able to write more complex equations and have the tool expand and optimize them). Will I finally have to learn Rust in order to add this all to Galette instead?
The progress on the afterburner approach has stalled because the Arduino used there does not have enough RAM. But the prototype was working fine. On the other hand, attempts to add it to the Minipro tool failed due to limitations in the hardware and firmware used (on which the Minipro team has no control). It looks like the good old parallel port based atfblast should not suffer from this.
If I'm going to try this, my first step would be, of course, to port atfblast to Haiku, because I'm not crazy enough to attempt doing development for Windows.
